同一個模型的 API，有人做出的 Agent 穩定得像個資深同事，有人做出的連 demo 都撐不完。模型人人都叫得到，效果卻天差地遠。

差距不在模型。模型是別人訓練的，權重凍結，你動不了。有人會說：可以 fine-tune 啊。沒錯，但動權重是另一個領域，資料、算力、維運成本完全是另一個量級，不在這個系列的範圍。而且多數 production 問題，在動權重之前，模型外面就有更便宜的解。這個系列 30 天要講的就是這件事：從「一個模型」到「一個能在真實場景穩定運作的 AI 系統」之間，有四層不動權重就能動的工程槓桿。

為什麼差距不在模型

拿 Claude Code 當例子。很多人以為它好用是因為模型強，但把同一個模型接上自己隨手包的 agent loop，效果就是差一截。決定表現的是模型外面那一整套東西：system prompt 怎麼寫、工具怎麼設計、權限怎麼把關、context 滿了怎麼壓縮、任務中斷了怎麼接續。

這套東西業界開始叫它 Harness（韁繩、套具）。同一匹馬，配不同的套具，能拉的車完全不同。API 上的模型人人一樣，能力差距來自你圍繞它蓋了什麼。

問題是「模型外面的工程」範圍太大，從改一行 prompt 到蓋一套自我改進的系統都算。所以我把它整理成四層地圖，這也是這 30 天的路線。

四層地圖

L1 Prompt Engineering 是最便宜的槓桿：改的是一次呼叫的輸入。它有效，而且有效的原因可以從 Transformer 的機制解釋，不是玄學。但它有天花板：prompt 調到極限，輸出還是不穩，因為問題常常不在指令怎麼下，而在模型根本沒看到該看的資訊。

L2 Context Engineering 往上一層：不只調指令，而是決定整個窗口裡放什麼。檢索（RAG）、記憶、壓縮，本質上都在回答同一個問題：這次呼叫，模型應該看到什麼？但 context 塞好塞滿，Agent 還是會跑歪，因為沒有系統在外面接住它的錯誤。

L3 Harness Engineering 再往上：動的是模型外面的整個執行系統。Session 怎麼設計、工具怎麼給、權限邊界畫在哪、能力怎麼模組化。這一層是「能 demo」和「能上線」的分水嶺。但 harness 蓋好了，系統也不會自己變好。

L4 Loop Engineering 是最大的槓桿：把你自己從迴圈裡拿出來，讓系統自己轉，而且越轉越好。系統自己找工作、自己驗證、自己記住做過什麼，每一次執行變成下一次的養分。評估和可觀測性在這一層是前提，而非附屬品：你能驗證系統做得對不對，才敢放手讓迴路轉起來。

為什麼是「層」，不是四個選項

因為每一層都以下面那層為地基。沒想清楚 prompt 為什麼有效，RAG 只是把垃圾塞進窗口；不會管理 context，harness 跑十輪就爆掉；沒有 harness 收集執行軌跡，評估和自我改進根本無米可炊。

這也是一張自我檢查表。大多數團隊停在 L1；會做 RAG 的到了 L2；L3 和 L4 有沒有做，決定了你的系統是產品還是 demo。你可以現在就問自己：我的系統蓋到第幾層？

這個系列會怎麼走，你會帶走什麼

路線很簡單：由下而上，一層一層走。先把 Prompt 層的機制和成本講透，再往上進 Context、Harness，最後走到 Loop。每一層講到極限的時候，你自然會知道為什麼需要下一層。我不在這裡把三十天的目錄寫死，每一層值得停留多久，我想保留跟著寫作節奏調整的空間。

但你最後會帶走什麼，現在就可以說清楚：

• 一套診斷語言：系統出問題時，你能判斷它卡在哪一層。是指令沒寫好、窗口塞錯東西，還是根本缺一套 harness？判斷對了層，才不會無止盡地調 prompt。
• 每一層的核心設計問題：內容不停在 API 教學。每講一個設計問題，我會盡量拿大家比較常聽到的知名開源專案（Claude Code、HermesAgent、mem0 這些）當例子，看真實系統在同一個問題上做了什麼取捨。
• 一個定位：系列最後我會留兩天，講為什麼我認為 AI Engineering 是現在最值得投入的工程領域之一，以及工程師可以怎麼站位。

明天從最底層開始：你寫的 prompt 為什麼有效？「請一步一步思考」這句話為什麼真的有用？答案在 Transformer 的機制裡，明天拆開來看。